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[57] ABSTRACT 

An efficient request-reply protocol for a client-server com- 
munication and data processing model. Under the novel 
protocol, a client sends a Request to a server and awaits a 
Reply. If the Reply is not sent before expiration of a timeout 
period in the client, the client sends a second Request. The 
server provides a conditional Acknowledge if a second 
Request is received from the client. Thereafter, the client 
waits for the server to transmit a Reply without the client 
sending additional Requests. Under normal conditions, the 
inventive protocol performs as well as the best prior art 
protocol (the optimistic model), while under abnormal 
conditions, the inventive protocol performs better than the 
optimistic protocol and only slightly worse than the prior art 
pessimistic protocol. Since normal conditions should prevail 
for a substantially longer amount of time than abnormal 
conditions, the present invention provides better average 
performance than either prior art client-server protocol. 

4 Claims, 3 Drawing Slieets 
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EFFICIENT REQUEST-REPLY PROTOCOL usually is a very precious resource. This becomes more 

FOR A CLIENT-SERVER MODEL apparent in a wireless network, with many nodes competing 

for limited radio bandwidth. 

BACKGROUND OF THE INVENTION FIGS. 2a and 2b are ladder diagrams showing the flow 

1 u* M f u T • 5 and timing of communications between a client-server sys- 

1. Field of the Invention according to a second prior art protocol. This protocol 
This invention relates to communication and data pro- takesan"optimistic" view of network characteristics. Again, 

cessing technology, and more particulariy to an efficient a Request is initially transmitted by a client 10 to a server 12 

request-reply protocol for a client-server communication over a communication network. A Reply is used to convey 

and data processing model. jg the result to the client 10. Since the Reply indirectly indi- 

2. Description of Related Art cates receipt of the Request by the server 12, a separate 
In recent architectures for data communication and data Acknowledge signal direcUy indicating such is unnecessary. 

processing technologies, many user workstations are typi- no separate Acknowledge is sent by the server 12. If 

cally interconnected by a computer network. The network server 12 sends the Reply before a time period TIM- 

may be of the direct connection type (e.g., LAN or WAN) or 15 EOUT elapses (i.e., the anticipated "normal" condition), 

a wireless type, or a combination of both. ^"^^y ^ PDUs are exchanged between the client 10 and the 

X „ * J ■ c u * *L « r * server 12, as shown in FIG. 2a, However, if the client 10 

Among current designs tor such architectures, the client- , ' • i r^- • . . 

server" model has become a typical model in which com- '^'^^ ^^P^^ ^thin the Timeout period, the 

. , ... 1.4U A chent 10 retransmits the Request under the assumption that 

puters on the network communicate with each other. A , . „ » . . ^ 

typical client-server interaction involves a cUem computer the pnor Request was lost m the network, 

requesting a server computer to perform a certain operation. Although this protocol is the most efiEcient for the best 

whereupon the server performs the operation and conveys scenario (only 2 PDUs exchanged), it behaves rather 

the result back to the client. ^^^^^^ operation perforaied on the server 12 takes 

„ ... r 1 , , a longer time than expected, as shown in FIG. 2b, When 

Currently, there are two basic types of protocols used by „^ „ T u • a ^ j *u 

, , . . ..L. t- J 25 completion or the operation by the server 12 IS delayed, the 

the client and server to communicate with each other based t *iau *j* • i.*u *un / 

„ , . , . , chent 10 has no way to deterimne whether the Request was 

on the two pacing parameters oi this architecture — network . . u *i- *l j i j- i *u 

- F 6 i' XT . 1 ^ lost or whether the server 12 was delayed m completmg the 

performance and server performance. Network performance « tt,^ „i,*^„* in ™u, ii 

^ . . . • ^1 f- . -1*. J operation. The client 10 can only assume that the server 12 

varies with, among other thmgs, network reliability and .u^«,;«.r>^„,.^^, ™t,o„^„^fo tu^ D»„..o..t 

, , „ r • -.L .L- did not get the prior Request, and so retransmits the Request 

bad. Server performance vanes with, among other thmgs, 3^ ^ ^ ^^^^^^ ^^^^ ^ ^^.^ 

load and operation complexity. ^^j^.^j^ retransmissions of the Request, resulting not only 

FIG. 1 is a ladder diagram showmg the flow and timing wastage of the network bandwidth but possibly overload- 

of communications between a chent-server system accord- ^^^^^^ ^ ^^^^ ^^^^ processing, which in turn could 

ing to a first prior art protocol. This protocol takes a ^^^^ ^^^^y operation being performed on the 

"pessimistic" view of network characteristics. As shown, a 35 server 12 

Request is initially transmitted by a cUent 10 to a server 12 Accordingly, it would be desirable to have a more efficient 

over a commumcation network The server 12 responds with ^^^^^^j dient-server model in a data communication 

an Acknowledge. The Acknowledge must be received by the processing system, 

client 10 within a first elapsed time period TIMEOUTj>£:- ™ 

Jf u * The present mvention provides such an improved proto- 

QussT or an error occurs. Such an error may represent, tor ^ ^ r r 

example, a disruption or failure by the server 12 or in the 

network. If the client 10 does not receive the Acknowledge SUMMARY OF THE INVENTION 

before the TIMEOUT^^y^^ time elapses, the client 10 xjjg invention provides an efficient request-reply protocol 

retransmits the Request until the client 10 receives an for a client-server communication and data processing 

Acknowledge. The timer value, TIMEOUT^^gt^^^y^ is a 45 model. Under the novel protocol, a client sends a Request to 

function principaUy of the network characteristics. That is, ^ server and awaits a Reply. If the Reply is not sent before 

the timer value is based upon some estimate as to how long expiration of a timeout period in the client, the client sends 

an Acknowledge should take to be sent to the client 10 by the ^ second Request. The server provides a conditional 

server 12. Acknowledge if a second Request is received from the 

After completing the requested operation, the server 12 50 client. Thereafter, the client waits for the server to transmit 

responds back to the client with a Reply containing the result a Reply without the client sending additional Requests, 

of the operation. If the client 10 does not receive the Reply xhe details of the preferred embodiment of the present 

within a second elapsed time period TiMEOVT^p^y, mea- invention are set forth in the accompanying drawings and 

sured from the receipt of the Acknowledge, the client 10 the description below. Once the details of the invention are 

conveys an error to higher layers of the application software 5s known, numerous additional innovations and changes will 

executing within the client 10. The timer value TIM- become obvious to one skilled in the art. 

EOUT^Piy is a function of a time estimate as to how long ntrci-DiDTroM nt7 ttjc no awtm^c 

the server 12 should take to perform the desired operation. ^^^^^ DESCRIPTION OF THE DRAWINGS 

The biggest advantage of this protocol is the separation of FIG. 1 is a ladder diagram showing the flow and timing 
the network and the server 12 performance variables, so 60 communications between a client-server system accord- 
even if the server 12 takes a longer time to reply than ing to a first prior art protocol. 

expected, only 3 protocol data units (PDUs) are exchanged FIGS. 2a and 2b are ladder diagrams showing the flow 

between the client 10 and the server 12 in the normal case. and timing of communications between a client-server sys- 

The problem with this protocol is that even for the best case tem according to a second prior art protocol, 

scenario, where the Request is not lost by the underlying 65 FIGS. 3a and 3b are ladder diagrams showing the flow 

network, there is an extra Acknowledge. This extra PDU and timing of communications between a client-server sys- 

results in unnecessary wastage of network bandwidth, which tem according to the protocol of the present invention. 
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Like refereace numbers and designations in the various 
drawings indicate like elements. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Throughout this description, the preferred embodiment 
and examples showD should be considered as exemplars, 
rather than as limitations on the present invention. 

FIGS. 3a and 3b are ladder diagrams showing the flow 
and timing of communications between a client-server sys- 
tem according to the protocol of the present invention. The 
inventive protocol initially takes an "optimistic" view of 
network characteristics. A Request is initially transmitted by 
a client 10 to a server 12 over a communication network. 
Under normal conditions, a Reply is used to convey the 
result to the client 10. Since the Reply indirectly indicates 
receipt of the Request by the server 12, a separate Acknowl- 
edge signal directly indicating such is unnecessary. If the 
server 12 sends the Reply before a time period TIMEOUT 
elapses (i.e., the anticipated "normal" condition), only 2 
PDUs are exchanged between the client 10 and the server 
12, as shown in FIG. 3a. 

However, if the client 10 does not receive the Reply 
within the Timeout period, the client 10 retransmits the 
Request under the assumption that the prior Request was 
"lost" in the network. When the server 12 receives this 
duplicate Request, the server 12 recognizes that the client 10 
is "impatient". To prevent further Requests from being sent 
for the same operation, the server 12 sends an Acknowledge 
to the Ghent 10 to indicate that the server 12 did receive the 
Request. When the client 10 receives this Acknowledge, 
client 10 knows that the Request was successfully received 
by the server 12, and thus the client 10 need not retransmit 
the Request again as further Timeout periods elapse. The 
client 10 simply waits for the Reply to arrive. 

If the client 10 does not receive an Acknowledge after the 
second Request, the client 10 assumes a network error has 
occurred, and continues to retransmit the Request (up to 
some selected maximum number of tries). If the chenl 10 
does not receive an Acknowledge before the maximum 
number of Timeout periods elapses, the cUent 10 conveys an 
error to higher layers of the application software executing 
within the chent 10. 

In the best case of good performance by the network and 
the server, only 2 PDUs are exchanged between the cHent 
and the server, giving the same performance for the inven- 
tion as the optimistic model during normal conditions. 
Under the worst case scenario, only 4 PDUs are exchanged 
between the client and the server (just one more than the 
pessimistic protocol). Accordingly, under normal conditions 
the inventive protocol performs as well as the best prior art 
protocol (the optimistic model), while under abnormal 
conditions, the inventive protocol performs better than the 
optimistic protocol and only slightly worse than the pessi- 
mistic protocol. Since normal conditions should prevail for 
a substantially longer amount of time than abnormal 
conditions, the present invention provides better average 
performance (i.e., fewer average PDUs) than either prior art 
client-server protocol. 

The present invention provides a number of advantages 
over the prior art. The normally optimistic view of the 
network results in the most efficient usage of the network 
resource in the best case conditions. The ability to differen- 
tiate between network errors and the performance charac- 
teristics of the server 12 provides for the most efficient usage 
of network bandwidth in the worst case conditions. Further, 
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the invention limits overloading of the server 12 in the worst 
case conditions. 

The inventive protocol may be implemented as identical 
or complementary computer programs executing on the 
client 10 and server 12, respectively. Each computer pro- 
gram is preferably stored on a storage media or device (e.g., 
ROM or magnetic diskette) readable by a general or special 
purpose computer, for configuring and operating the com- 
puter when the storage media or device is read by the 
computer to perform the protocol described above. The 
inventive protocol may also be considered to be imple- 
mented as a computer-readable storage medium, configured 
with a computer program, where the storage medium so 
configured causes a computer to operate in a specific and 
predefined manner to perform the protocol described above. 

A number of embodiments of the present invention have 
been described. Nevertheless, it wiU be understood that 
various modifications may be made without departing from 
the spirit and scope of the invention. Accordingly, it is to be 
understood that the invention is not to be limited by the 
specific illustrated embodiment, but only by the scope of the 
appended claims. 

What is claimed is: 

1. A method for communicating between a cMent and a 
server coupled by a network, comprising: 

(a) transmitting a request to perform an operation, from a 
client to a server over a network; 

(b) retransmitting the request to perform the operation, if 
the chent does not receive a reply conveying a result of 
the request, fi-om the server before a time period 
elapses; 

(c) transmitting an acknowledge signal indicating receipt 
of the retransmitted request by the server, from the 
server to the client over the network, if the server 
receives the retransmitted request before generating the 
reply; and 

(d) transmitting the reply from the server to the client after 
the server has generated the reply. 

2. The method according to claim 1, further comprising 
after step (c), 

(e) suspending further retransmissions of the request from 
the chent to the server, in response to receipt by the 
client of the acknowledge signal. 

3. A method executed by a client in communicating with 
a server over a network, comprising: 

(a) transmitting a request to perform an operation to a 
server over a network; 

(b) waiting for a reply conveying a result of the request 
from the server; 

(c) retransmitting the request to the server only if the reply 
is not received from the server before a time period 
elapses; 

(d) waiting for the earher arriving of the reply or an 
acknowledge signal indicating receipt of the retrans- 
mitted request by the server; and 

(e) suspending retransmissions of the request to the 
server, if the earher arriving of the reply or the 
acknowledge signal is received from the server before 
the time period elapses, otherwise retransmitting the 
request to the server and jumping back to step (d). 

4. A method executed by a server in communicating with 
a client over a network, comprising: 

(a) receiving a request from a client over a network, and 
taking no action in response to the request to transmit 
an acknowledge signal indicating receipt of the request 
back to the client; 
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(b) generating a reply conveying a result of the request; (b) transmitting the reply conveying the result of the 

(c) transmitting an acknowledge signal to the client, if a request to the client, after generating the reply, 
retransmission of the request is received from the client 

before the reply is generated; and ♦ * ♦ ♦ * 
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